BBS Toolkit/BBS Toolkit.iso/doors_2/oman_174.zip/OMAN.HLP

Text File | 1992-01-27 | 80KB | 1,753 lines

;
;     oMan Help v1.74 for The Opus Manager v1.7x  **** 27-Jan-92
;     Oman copyright (C) 1989-92 by Tom Kashuba and Ulf Nilsson
;                      -- All Rights Reserved --
;     Opus<tm> and Copyright (C) by Wynn Wagner III -- All Rights Reserved
;
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\MAINMENU\ ----------------------------------------------------------------

i H E L P                         Main Menu                         Page 1 of 3 
L


 (O) Outbound Hold Area Manager.

     Manipulates the mail already waiting to be sent.  You can change the
     address or priority of pending mail, create POLLS, File-Sends, or
     File Requests, and more.

 (U) User File Manager.

     Edits the User Database.  With it, you can add, modify, delete, list
     or sort user records.  If there is no user file, it can create one.

 (E) Event Schedule Manager.

     Edits the schedule that is used by Opus to control its mail operations
     and sysop paging (yell). It adds, deletes, edits, and sorts events and
     can create a new schedule.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                         Main Menu (cont)                  Page 2 of 3 
L


 (G) Global Data Editor.

     Edits common (global) data.  At the present time, it only includes the
     System Call Count and the Quotes file byte pointer (sets offset of next
     quote to show) as stored in the event data file.  Currently, it does not
     handle the special 'common data file' that can be defined in Opus.Prm.

 (N) Nodelist Editor.

     Edits the ACTIVE nodelist data and index files for those times, in
     between weekly nodelist updates, that you need to add, deleted, or
     modify a node.  Also searches and lists.

 (A) Area Manager.

     Edits the System Files that defines the Message and Files Areas. It can
     list, add, modify, or delete areas and will create new directories, if
     required, and can create news ones, when none exist.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                         Main Menu (cont)                  Page 3 of 3 
L


 (P) Operational Parameters Screen

     Displays the oMan operating parameters screen that is initially shown
     every time the program is first run.  Use it to verify or review the
     paths and settings used during the current usage of the program.

 (L) Log File Scanner

     Compiles and displays a summary of the OPUS log file. It skips entries
     in betweeon sessions, color codes different session types, and back
     scans to attribute rings and other unidentified data to their caller.
     Still experimental, its initial compile phase is longer than ideal.

 (Q) Quit oMan

     Returns you to DOS, leaving you in the directory you started from.
\\
;
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\AMAN\ --------------------------------------------------------------------

i H E L P                       AreaMgr Help Topics                             
L


      
HPress letter of desired topic or use PgDn to browse them all.
L


        
HO
L - Overview                   
HF
L - Field Descriptons


        
HN
L - Area Navigation


        
HA
L - Area Structure & Access    
HE
L - Echo.Ctl Skeleton


        
HC
L - Maintenance Commands     
HESC
L - Quit this Help


    Enter: (letter), ESC=Quit: ONAFE|[+_.Q}C
OAMANOVR
NAMANNAV
AAMANACF
FAMANFLD
EAMANmech
CAMANmaint
Q
[
;
;
;

\AMANOVR\ ------18 lines deep----------------------------------------------

i H E L P                           Overview                        Page 1 of 2 
L

 The Area Manager is a sub-function of the Opus System Manager which allows
 you to inspect, edit, or update the Opus Area Database which contains all
 data that defines, and controls access to, the file and message areas.

 It uses the full screen to display one system area record at a time, showing
 all of its fields.  Using navigation keys, the operator can move through the
 areas incrementally using the IBM keypad (or the WordStar<tm> diamond keys,
 by jumping to specific ones, or by searching.

 When the Area Manger is first run, it displays a DEFAULT area which is not a
 real one but is used to hold the default field values that will be pre-loaded
 into the fields of any newly created areas.  It is stored in a special disk
 file and, if not found, is created using the values in the record for System
 Area #0.  If there is no System #0, basic program defaults are used.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                        Overview (cont)                    Page 2 of 2 
L

 You can use the AreaMgr to make quick, general, or total changes to the area
 definitions.  However, if you are also using an Opus configuration program
 such as SALT then you must remember to run its counterpart, PEPPER, to
 make an updated control file that reflects the changes you made with oMan.

 One should note that since any one system record contains the definitions for
 both the file area and message area of the same number, the common fields
 such as Area Privilege, Area Locks, Area Menu, etc, apply to both.  Any
 changes made to common fields should be done with respect to the effect on
 access to both the file and message areas defined.

 Field edit keys are highlighted letters before a ')' in the field label.
 Often, more than one key needs to be pressed.  These cases are shown by a
 '---' that links the parent command or by lower case perfixes when that's not
 possible.  Eg, 'fdD)ir' means press F+D+D and 'E)xt--P)riv' means press E+P.
;
;
;
\AMANNAV\ -----------------------------------------------------------------

i H E L P                         Navigation                        Page 1 of 1 
L

 The Area Manager uses much the same cursor key and WordStar key combinations
 to move among the areas as by the other oMan function movement commands.

     Navigation Command     CursorKeys         Keyboard

     
HJump to Area#
L .......... 
H      
L ......... 
HA+(number)
L

     
HNext USED Area
L ......... 
H[DOWN]
L ......... 
HCtrl-X
L
     
HPrev USED Area
L ......... 
H[UP]  
L ......... 
HCtrl-E
L

     
HNext Area No.
L .......... 
H      
L ......... 
H> .
L
     
HPrev Area No.
L .......... 
H      
L ......... 
H< ,
L

     
HFirst Area
L ............. 
H[Home]
L ......... 
H1
L (one)
     
HLast Area
L .............. 
H[End] 
L ......... 
H0
L (zero)
;
;
;
\AMANACF\-----------------------------------------------------------------

i H E L P                    Area Record Structure                  Page 1 of 2 
L

  ╔═1═══════════════════════╗    Each Opus system area record can separately
  ║╔══2══════════════════════╗   define a message area and a file area.
  ╟║╔═══3═════════════════════╗  Though they share the same area number and
  ║║║  Menu & Barrier Control ║  definition record, they're independent of
  ║║║─────────────────────────║  each other except for the OtherMenu# and
  ║║║  Message  │   File      ║  BarrierPath fields which affect both areas.
  ╚║║  Section  │  Section    ║  One, both, or neither area may be defined
   ╚║   Items   │   Items     ║  but, if both are, it's always nice to have
    ╚═════════════════════════╝  them topically related, if possible.

 You may find it easier to think of the set of File and Message areas as
 completely independent systems, the equal numbered records of which just
 happen to share a common data record.  In future versions, this independency
 will be even further delineated.

 User access to the file or message sections of any given area is separately
 controlled by an ACCESS PRIVILEGE and LOCK set for each.  A user must have
 a privilege that is at least as high as the ACCESS privilege to access the
 given Message or File area and at least the KEY's that match any LOCK's.
;
;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                    Area Record Structure                  Page 2 of 2 
L

 Much beyond the basic access controls of Privilege and Locks, each section
 defines many other items that define an area such as the paths to any area
 directories, special operation modes or flags, and function overrides that
 are yet higher privileges and/or locks required to use certain functions
 such as Downloading or Message Entry.

 Eg, if an area's Files Section had an Access Privilege of NORMAL, it's
 Download Privilege is set to WORTHY and the user has a privilege of NORMAL,
 then the user would be able to enter the area but would not be able to use
 the Download command.  This is useful when you want to allow users to access
 and download from most file areas but want to limit their access in just
 certain areas.  However, if you wanted to limit Downloads the same way in
 all file areas, then it would be simpler to use the Menu Manager to set File
 Menu's Download command privilege, instead.

 Note: With overrides, it is useless to set them lower than the area's
 general access level since the only way a user could get into the area is
 by having the higher level needed for the basic access so lower privileged
 users would never be able to get into the area to use the function(s).
;
;
;
\AMANFLD\-----------------------------------------------------------------

i H E L P                 Field Descriptions: COMMON                Page 1 of 3 
L


 O)therMenu# ... The numeric extension of an alternate menu control file to
                 use for the area.  Eg, if set to '001' and the current
                 language set was English, then Opus would use English.001
                 instead of the default (English.Mnu) menu file for the area.
                 This allows for custom menus to be shown to certain users
                 who are allowed into special areas.


 B)arrierFile .. If defined, this field specifies a Barricade Security
                 file that contains a list of passwords and privileges.
                 If a user enters an area with such a file defines, they
                 are asked to enter a password which must be in the list.
                 If it is, they are then given the associated privilege
                 for the duration of their stay in the area.  This is
                 very handy for giving certain callers high privileges
                 for only certain areas.
;
;
;
----------------------------------------------------------------

i H E L P                 Field Descriptions: FILES                 Page 2 of 3 
L

 P)rivilege .... Minimum user privilege to access the file area.
 L)ocks ........ Minimum user keys (locks) to access the file area.
 T)itle ........ Area's title (displayed above file menu)

 D)ownload
 ├──D)ir ....... Directory where the area's downloadable files are.
 ├──P)riv ...... If set, the overriding privilege to download.
 ├──L)ocks ..... If set, the overriding locks to download.
 └──A)lt-List .. If set, alternate files list to use instead of FILES.BBS.

 U)pload
 ├──D)ir ....... Directory where the area's uploads are deposited.
 ├──P)riv ...... If set, the overriding privilege required to upload.
 └──L)ocks ..... If set, the overriding locks required to upload.

 X)ternal
 ├──P)riv ...... If set, the overriding privilege to go outside.
 └──L)ocks ..... If set, the overriding locks required to go outside.
;
;
;
-------------------------------------------------------------------------

i H E L P                 Field Descriptions: MESSAGES              Page 3 of 3 
L

 P)rivilege .... Minimum user privilege to access the message area.
 L)ocks ........ Minimum user keys (locks) to access the message area.
 T)itle ........ Area's title (displayed above message menu)

 M)sgType ...... Type of message area (Local, Network, or Echomail)
 S)cope ........ Entry privacy type (Public, Private, Both, or Read-Only)
 D)ir .......... Directory where the messages are stored.

 E)ntry
 ├──P)riv ...... If set, the overriding privilege to enter messages.
 └──L)ocks ..... If set, the overriding locks to download.

 X)ternal
 ├──P)riv ...... If set, the overriding privilege to go outside.
 └──L)ocks ..... If set, the overriding locks required to go outside.
;
;
;
\AMANmaint\-----------------------------------------------------------------

i H E L P                  Area Maintenance Commands                Page 1 of 1 
L

     C - Copy current area record onto another one (overwriting it).

     H - Hunts (finds) an area by searching area titles for a piece of text.

     W - Write the current area to disk, saving any changes made to it.

     R - Restore current area with its disk image (erases unsaved changes).

     L - Produces various area listings to screen, printer, or file.

     D - Deletes the current system area by deleting its record.

     Z - Zaps (resets/clears) current system area back to default values.

     E - Creates partial ECHO.CTL skeleton file (for very special cases).

     ! - Redisplays entire screen (if it gets dirtied with line noise).

 ESC/Q - Quit the Area Manager and return to the main oMan Menu
;
;
;
\AMANmech\-----------------------------------------------------------------

i H E L P                        Make Echo.Ctl                      Page 1 of 1 
L

 The Area Manager's "Make Echo" command (E) creates a skeleton ECHO.CTL file
 based on the information in the existing System Area files (SYSTEM##.DAT).
 It is for special situations only and would seldom be used as SALT can
 create a complete ECHO.CTL file.  The ECHO.CTL file produced by this
 command CANNOT be complete since echo link addresses are not stored in the
 system records.  Instead, this command asks for a common list of addresses
 to append to each and every echo control line produced.

 This command should *ONLY* be used in *SPECIAL* cases where:

  a) your SALT control file was lost
  b) your SALT control file does not at all reflect your system areas
  c) a common address list for all echo areas would be sufficient

 When invoked, you are asked to edit or confirm the destination file
 and the common address list to append.  If the confirmed file exists,
 you are asked to confirm its overwriting.  For testing, you can, and
 should, enter some other file path\name to verify the result.
;
;
;
\\
;
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\UMAN\ --------------------------------------------------------------------

i H E L P                 User Manager Help Index                   Page 1 of 1 
L


                       
HO
L - Overview

                       
HN
L - Record Navigation

                       
HM
L - Maintenance [Menu] Commands

                       
HF
L - Field descriptions

                       
HP
L - Message Pointer Editor

                       
HV
L - VIEW and GLOBAL commands

                       
HH
L - How To ...

                     
HESC
L - Quit this Help


              Command: ONMFHVP|[+_.}Q
OUMANOVR
NUMANNAV
MUMANMNT
FUMANFLD
PUMPTR
HUMANHOW
VUMANVIEW
Q
[
;
;
;

\UMANOVR\ ------18 lines deep----------------------------------------------

i H E L P                       Overview                            Page 1 of 2 
L

 The UserMgr allows you to inspect, edit, and update the Opus User Database
 which contains all data relating to users of your system and controls their
 access to it.

 It uses a one-record-per-screen format wherein all possible fields applicable
 to any one user are displayed together on one screen.  Using navigation keys,
 the operator can move through, jump to, or search for user records.

 When UserMgr is first invoked, it displays the FIRST record in the database
 which has the reserved meaning of be that of the main system operator.

 It also checks and maintains the user database index in a transparent
 manner that needs no manual operation.  For information only, it displays
 the index key of the current user record and recalculates it each update.
\- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                     Overview (cont)                       Page 2 of 2 
L

 Typically, UserMgr is used on a regular basis (daily to weekly) to inspect
 or adjust user information such as:

   o Names, location, modem, etc.   o Screen, help, and message controls
   o System access controls         o Usage, call, and FidoNet Accounting
   o Expiration controls            o Special Announcements
   o Custom Welcome Screen          o Special logon screen

 In addition to specific record modificatons, the overall database can be
 manipulated through the use of various maintenance functions such as:

   o Removing user records          o Searching for abnormal data values
   o Sorting users in various ways  o Adding and clearing user records
   o Producing user listings        o Custom Welcome File Management
;
;
\UMANNAV\ -----------------------------------------------------------------

i H E L P                     Navigation                            Page 1 of 1 
L

 UserMgr uses much the same cursor key and WordStar key combinations to move
 among the records as is used in other oMan movement commands.

     Navigation Command     CursorKeys           Keyboard

     
HJump to User#
L .......... 
H       
L ......... 
HJ+(number)
L

     
HNext User
L .............. 
H[Right]
L ......... 
HCtrl-D
L
     
HPrev USer
L .............. 
H[Left] 
L ......... 
HCtrl-S
L

     
H1st User
L ............... 
H[Home] 
L ......... 
H1
L (one)
     
HLast User
L .............. 
H[End]  
L ......... 
H0
L (zero)

     
HFind User
L .............. 
H       
L ......... 
HF
L (Find Menu)
;
;
\UMANMNT\ -----------------------------------------------------------------

i H E L P                     Maintenance Commands                  Page 1 of 2 
L

 
H*) ShowPws
L ....... Hide/Display user password field
 
H@) CWF-Mgr
L ....... Display/Edit/Del/Attach Custom Welcome File
 
HMaxRec
L ........... Highest record number on file

 
HHOME
L ............. Jump to first user record
 
HEND
L .............. Jump to last user record
 
HLEFT
L ............. Jump to previous (lower) user record
 
HRIGHT
L ............ Jump to next (higher) user record
 
H### JmpRec
L ....... Jump to record number (no command, just number)

 
HR) Restore
L ....... Reloads record from disk - voids pending changes
 
HW) Write
L ......... Writes record to disks - commits pending changes
 
HZ) ZapDef
L ........ Erase and Resets record to new record defaults

 
H!) Redraw
L ........ Redraws entirs screen - for line noise via remote
 
HA) Append
L ........ Appends new record to end of file and jumps to it
 
HC) ClearLim
L ...... Resets only the KB and MINS daily usage totals
;
----------------------------------------------------------------------------

i H E L P                     Maintenance Commands (cont)           Page 2 of 2 
L

 
HO) Output
L ........ Like L)ist but outputs to device w/o ANSI codes
 
H^) Edit City
L ..... Auto-Preening of C)ity Field using OMANCITY.FIX rules
 
HL) List
L .......... Lists all or selected users with full-screen paging
 
HF) Find
L .......... Finds all or selected users

 
HK) Kill
L .......... Marking records as KILL for later removal by PACKing
 
HT) Tag
L  .......... Tag records as part of 'groups' for later reference.
 
HP) Pack
L .......... Restructures user file, dropping records marked KILL
 
HS) Sort
L .......... Restructures user file, sort in var. selected ways
 
HI) Index
L ......... Regenerates the User Index file if ever corrupted.
 
HV) View
L .......... Sets View Filter which limits records shown/listed.
 
HG) Global Update
L   Sets fields to reset of records in current view.
 
HE) Export
L ........ Exports user data in MailMerge<tm> format.
 
HM) MsgPtr Edit
L ... Edit user's Last Message Read (LMR) pointer table.
 
H?) Help
L .......... Invokes this full-screen help facility
 
HQ) Quit
L .......... Return to main oMan function menu
 
H\) Quit to DOS
L ... Exit Oman entirely, returning to DOS.
\
;
;
;
\UMANFLD\ -----------------------------------------------------------------

i H E L P                     Field Descriptions                    Page 1 of 4 
L


H   Record Status and Info Fields
L
   
HKILL
L ................ KILL flag indicating pending removal by PACKing.
   
HABCD
L ................ GROUP flag(s) showing any groups record is in.
   
HUPD
L ................. Record has been UPDated and needs writing.
   
HCWF
L ................. Record has matching Custom Welcome File.
   
HRecNo
L ............... Displayed record's position in database
   
HIdxKey
L .............. Index key used to index user name


H   U)ser Group  (Items relating to personal user data)
L
   │
   ├─ 
HN) Name
L .......... Name or code used to indentify caller
   ├─ 
HC) City
L .......... City or location of user
   ├─ 
HT) True
L .......... User's true name if different than logon name
   ├─ 
HM) Modem#
L ........ User's modem number for call-back or reference
   ├─ 
HK) Keys
L .......... Special access keys to match locks on features
   ├─ 
HL) Language
L ...... Language set number to use for this user
   ├─ 
HP) Privilege
L ..... User's access privilege level
   ├─ 
HW) PassWord
L ...... Private password to verify user's indentity
   ├─ 
HU) UserListing
L ... Controls use of NAME, CITY, & TIME in user list
   └─ 
HR) Remarks
L ....... Brief remarks or comments relating to user
;
;
;
--------------------------------------------------------------------------

i H E L P                     Field Descriptions (cont)             Page 2 of 4 
L

 
HO) OEC-1
L ............ Special, 1st OEC text file to show at logon
 
H#) AnnounceCounts
L ... No of times to show each of 5 SPANN# OEC texts


H   H)istory Group  (Items relating to usage history)
L
   │
   ├─ 
HL) Last Call
L ..... Date & Time (YY-MM-DD HH:MM:SS) of last call
   ├─ 
HC) Calls Todate
L .. Number of times the user called the system
   ├─ 
HT) 24hr Usage
L .... Total minutes online on last call's day
   ├─ 
HK) 24hr-DnLds
L .... Total KB downloaded  on last call's day
   ├─ 
HM) Message Area
L .. Message area last accessed by user
   ├─ 
HF) File Area
L ..... File area last accessed by user
   ├─ 
HD) DnLd [Tot]
L .... Total KB downloaded by user, to date
   ├─ 
HU) UpLd [Tot]
L .... Total KB uploaded by user, to date
   ├─ 
H+) Credits $
L ..... Total funds allocated for user's net mailings
   ├─ 
H-) Debits $
L ...... Total charges incurred by user's net mailings
   └─ 
H=) Level CR/DB
L ... Equally reduces CR & DB till DB=0 and CR=Balance
;
;
;
------------------------------------------------------------------------

i H E L P                   Field Descriptions (cont)               Page 3 of 4 
L


H e(X)piration Group  (Items related to User Expiration Control)
L
   │
   ├─ 
HC) by Calendar
L ... Expire user when (C)alendar date passed
   ├─ 
HD) Expiry Date
L ... Expiry date to use with expiry by C)alendar
   ├─ 
HR) Remaining Days
L  No of days till expiration date (neg=passed).
   │
   ├─ 
HM) by Minutes Used
L Expire user when Debit Minutes = Credit Minutes
   ├─ 
H+) Credit Minutes
L  Online minutes (todate) given to user
   ├─ 
H-) Debit Minutes
L   Online minutes (todate) used by user
   ├─ 
H=  Minute Balance
L  Info only: Minutes Given less Minutes Used
   │
   ├─ 
HA) Axe User
L ...... Log user off if they are expired
   └─ 
HV) Lower Privilege
L Demote user's privilege if they are expired
;
;
;
------------------------------------------------------------------------

i H E L P                   Field Descriptions (cont)               Page 4 of 4 
L


H   D)isplay Group  (Items related to the user's interface)
L
   │
   ├─ 
HA) Ask configure
L   Ask user about configuration at logon
   ├─ 
HH) Help Level
L .... Amount of text shown at menus
   ├─ 
HL) Lines
L ......... No of lines usable by Opus on user display
   ├─ 
HC) Columns
L ....... No of columns usable by Opus on user display
   ├─ 
HT) TAB Handling
L .. Use ASCII TABs to compress multiple spaces
   ├─ 
HN) Nulls after CRs
L No of NULLs to send (as a delay) after each line
   ├─ 
HM) MORE? Prompting
L Pause listings with a "MORE?" after each screen
   ├─ 
HV) Video Enhance.
L  Set screen ehnancement to ANSI or AVATAR
   ├─ 
HE) Editor Type
L ... Set message editor to full-screen or line-by-line
   ├─ 
HF) Form Feeds
L .... Use ASCII Form-Feed to clear screen
   └─ 
HI) IBM Graph Symb.
L Allow (or convert to ASCII) IBM text graphics
;
;
\UMANVIEW\ ----------------------------------------------------------------

i H E L P                   View Filter Setting                     Page 1 of 1 
L

  The view filter limits the records that can be 'viewed' by the UserMgr by
  comparing each of those values set on the view setting screen to the
  matching fields in each user record.  If *all* of the view fields match
  as indicated, then the record is considered to be viewable.  Please note
  that all fields have to match to be in the view (LOGICAL AND). Each VIEW
  field is compared according to the (*, =, or !) that leads the field:

     (*) "no care",  (=) "must equal", and (!) "must not equal".

  The VIEW filter is also used by the GLOBAL function to determine which
  records are chosen for modification but it uses a separate Global fields
  screen for setting the actual values to modify the selected records with.
  Because of this, both screens look very similar but should not be confused.
  When selecting the Global option, you first get this VIEW screen to verify
  that your view settings are correct.
;
;
\UMANGLOB\ ----------------------------------------------------------------

i H E L P                  Global Field Update                      Page 1 of 1 
L

  The Global reset function scan each user record in the entire user file
  and, for each record that is within the current view, will set those
  fields filled in on the global data screen with the given values.  Due
  to the great importance of the current view being set correctly, you are
  first presented with Define View screen to set or verify its values.
  Upon accepting the view citeria, you are then presented with the global
  fields screen which look almost identical to the Define View screen since
  most of the fields happen to be the same.

  Eg, if you wanted to flag all users who have not called in 30 days with
  the KILL mark so the next PACK will eliminate them, you would set the
  view scope to show for "AGE  30 *" meaning "from 30 up to any days old"
  and set the KILL mark on the Global field reset screen.

  After selecting R)un, you are asked if you want to run with or without
  confirmation.  If without confirmation, it will first precount the records
  that will be altered as a safety check and ask for a final confirmation.
;
;
\UMPTR\ ----------------------------------------------------------------

i H E L P           Last Message Read (LMR) Pointer Table           Page 1 of 1 
L

  The M)essage Pointer function, allows you to display or alter a user's
  Last Message Read (LMR) table which tracks their last message number
  read in each of the 255 possible message areas.  All 255 possible
  values are edittable, even if there is no matching message area
  defined; in which case there's no harm (nor any real effect).

  Areas with an LMR pointer of zero are displayed as a single (.) for
  clarity; zero being the value for an area that the user has not
  accessed yet.  Since there are 255 possible LMR values, two screen
  pages are used to display them all.  To change between them, press
  'P' (for page) or use the PgUp, PgDn, Up, or the Down cursor keys.

  To alter an area's LMR value, enter it's area number; no command
  prefix is needed.  The cursor will jump to the desired slot and you
  will be prompted for the new LMR value.  If you request an area that
  is not currently displayed, an automatic page switcher will flip the
  page, jump to the desired area slot, and ask for the new value.
;
;
\UMANHOW\-----------------------------------------------------------------

i H E L P                 Selected How-To Topics                                
L


         T ... Tidying up unwanted, messy, or bad user records

         M ... Marking records as KILL for removal and/or listing

         P ... Packing the file to remove records marked as KILL

         S ... Sorting the user file into various orders

         L ... Listing users to screen, file, or device

         A ... Adding new users with APPEND

         C ... Using Custom Welcome Files

     -=> TMPSLAC|[+_.^{}Q
TUMANH-T
MUMANH-M
SUMANH-S
PUMANH-P
LUMANH-L
AUMANH-A
CUMANH-C
Q
[
{
^
;
;
\UMANH-T\ -----------------------------------------------------------------

i H E L P              HowTo: Tidying the User File                 Page 1 of 3 
L

   Typically, you will want to review and clean up the user database every
   few days or weeks.  When a system runs in normal mode without any
   pre-registration requirements, there will be many new records appended
   to the file for all of the new callers.  These records will often have
   ficticious or obscene names, improper locales, or other anomalies.

   With a little manual editting and use of the Global Update, Pack, and
   sort options you can quickly put the file into a more presentable order.

   1) Using the L)ist A)ll command, inspect the records around the point
      where all new users since your last update would start.  You will
      quickly see where bad records start and know where to start editting.

   2) After leaving the L)ist function, Jump to that desired record by
      entering its number.  You will see that record displayed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              HowTo: Tidying the User File                 Page 2 of 3 
L

   3) Using the record movement keys, move through the records looking for
      and changing any errant data.  For those that you fix, will most likely
      be correcting the location data or deleting the record completely. To
      delete the record, in this case, to mark it as KILL for later removal
      by the next PACK operation.

   4) When you are done with your record editting, you should probably then
      use the L)ist K)ill option to show all records that have been marked
      for KILL.  This is to ensure you won't kill a record you didn't mean
      to.  If any were incorrectly set, just jump to it and remove KILL.

   5) To remove all records marked KILL, use the PACK command.  This is a
      powerful command which completely rewrites the user file, dropping
      any records marked KILL.  See the "How To" section for more about it.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              HowTo: Tidying the User File                 Page 2 of 3 
L


   6) As a last step, you may wish to re-sort the file to place the
      records in a particular order such as by privilege, uploads, or
      some combination of those and other fields.  Sorting by uploads, eg,
      would cite those users with the most uploads by placing them at the
      front of the file and would be shown, first, in user lists.

   7) When you're done with all user files restructuring, you may want
      to list the records to te printer or to a disk file for printing
      later as a reference and backup.

   An important side-benefit from user maintenance such as this is that
   you really get to know your user's habits and can better respond to
   their needs.  After you, you are now an Information Provider!
\
;
;
\UMANH-M\ -----------------------------------------------------------------

i H E L P              HowTo: Marking Records as KILL               Page 1 of 1 
L

   The KILL command alternately turns a record's KILL flag ON or OFF.  When
   a record is marked KILL, you will see the indicator "KILL" on the top of
   the screen.  The KILL status is not temporary but is stored in the disk
   record so it remains until you turn it off or you PACK the user file.

   When you mark a record as KILL, the next PACK operation will remove it
   from the file.  Because of this, each time you mark a batch of records
   as KILL, you should do a PACK at the next opportunity to be neat.
;
;
\UMANH-P\ -----------------------------------------------------------------

i H E L P              HowTo: PACK'ing the User File                Page 1 of 1 
L

   The PACK command is used to physically remove all records that have been
   marked as KILL.  No other records are removed.  The PACK command literally
   copies all records that are marked as KILL to a new file, names the old
   one to a back up name, renames the new to the proper name and, if all
   goes well, deletes the original.  The order of users remains unchanged.

   Because of its necessary user file shuffling, PACK cannot be used when
   there might be an Opus system running.  This would be the case if you
   were running a multitasked or networked system with one or more Opera
   running while you do maintenance at the same time.

   Because doing so would damage the user file, the User Manager will not
   allow you to PACK if it detects certain marker files that Opus creates
   while it is active.  In the case of tryingto pack after an Opus system
   crash, the marker files will still be there and the PACK disallowed
   until you reboot Opus and have it exit normally.

   
fWARNING
L: If you run oMan with other Opera in a multitasked scenario,
   you must not use PACK.  Doing so can destroy the user file.  oMan tries
   to sense and prevent this but common sense is always more reliable.
;
;
\UMANH-S\ -----------------------------------------------------------------

i H E L P              HowTo: SORT'ing the User File                Page 1 of 2 
L

   The SORT command is used to physically re-order user records by any
   number and combination of several fields such as Privilege, Name, and
   Uploads.  Sorting ignores any KILL or GROUP marks, treating them like
   any other.  You will probably want to PACK the file before sorting.

   
fWARNING
L: Like the PACK command, sorting completely rewrites the user file
   and must not be used when an Opus system is active.  oMan tries to sense
   this fact and prevent it but, as always, common sense prevails.

   When SORT is invoked you are asked how many initial records should be
   skipped (ie, left where they are).  It is mandatory that you skip at
   least the 1st record because Opus gives some special privileges to the
   physically first record which should always be the key Sysop's record.
--------------------------------------------------------------------------

i H E L P              HowTo: SORT'ing the User File                Page 2 of 2 
L

   The user sort function allows you to order the file according to the
   any grouping of the following selected items:

     N)name .... Ascending ... Logon ID (name) field
     C)alls .... Descending .. Calls made to system
     U)ploads .. Descending .. Uploads todate
     R)Up/Calls  Descending .. Uploads/Calls (x100 for easier viewing)
     P)rivilege  Descending .. Access privilege
     A)ge ...... Ascending ... Days since last call

   Some example sort orders:

     "N" ....... Name only
     "PN ....... Privilege, then Name
     "PAN ...... Privilege, then Age, then Name
     "PRAN" .... Privilege, then Upload rate, then Age, then Name
;
;
\UMANH-L\ -----------------------------------------------------------------

i H E L P              HowTo: LIST'ing the User File                Page 1 of 1 
L

   The listing of users comes in two flavors.  One for on screen paging with
   full video enhancements, L)ist, and the other for outputting to a file
   or device, O)utput.

   You will most likely end up using the on screen L)ist command very often
   as it is the fastest way to get an overview of your user base.  Both
   flavors allow you list A)ll users or to limit the listing to records
   marked for K)ILL, those with associated C)ustom Welcome Files, or those
   with a piece of text in either the logon name or locale fields.

   Listing is also handy to do spot checks for corrupt user data or for
   gauging the amount of new user activity your system has.  It is also
   convenient to run after any maintenance, KILL marking, packing, and
   sorting you may do to verify the results of those actions.
;
;
\UMANH-A\ -----------------------------------------------------------------

i H E L P              HowTo: ADD'ing User Records                  Page 1 of 1 
L



   On many systems, new users are mostly added by Opus when the user first
   logs on.  There are other times, however, when you need to add a new
   user by hand such as when you want to spare a friend the trouble of going
   through a new user logon sequence and possible privilege adjustment.

   There are two basic methods with which to manually add a new user.  You
   can use the APPEND command to append a brand new user record at the end
   of the file or you can re-use an inactive or garbage record.

   With APPEND, you are provided with an new, empty, and initialized record
   for filling out whose fields you then set, as needed.

   With re-use, you locate a user record that is no longer needed and use
   the Z)ap command to clear all of its fields to a default state and then
   set the fields, as needed.
;
;
\UMANH-C\ -----------------------------------------------------------------

i H E L P              HowTo: Custom Welcome Files                  Page 1 of 3 
L

   An interested but little used Opus feature is the display of what are
   called "Custom Welcome Files".  These are Opus Embedded Command (OEC)
   text files that are specific to each user and, if present, are displayed
   just after the use signs on.

   One drawback to CWF's that is probably the reason for their limited use
   is that their names are based on the record position of the corresponding
   user record.  This means that any operation that alters the position of
   user records will place these files out of sync with the user file and
   cause the wrong user to see a CWF that was meant for another.

   Another drawback is that you have to delete them after their purpose has
   been met which is difficult because you don't know if the caller has seen
   it or not.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              HowTo: Custom Welcome Files                  Page 2 of 3 
L

   The User Manager takes these drawbacks into account and goes to the
   trouble of renumbering the CWF files in accordance with the changes in
   position of the user records that results from the PACK and SORT commands.

   It also displays an indicator on each user record when a CWF is present
   and will flash it if the use has logged on since the file was last
   created or changed.

   To further support CWF's, the User Manager has a CWF editting sub-system
   that allows you create, display, edit, or delete a CWF file for any one
   user record and the ablity to attach any one of several master CWF's
   that you have precomposed for common situations.  In this latter case,
   a copy of the master CWF is used to make a specific CWF for the current
   user record.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              HowTo: Custom Welcome Files                  Page 3 of 3 
L

   Typically, you may want create master CWF's that tell the user things
   like "There is a problem with your code, please call" or "Thanks for
   the uploads.  You have been made a 'Worthy' user".

   Master CWF's are stored in the same directory as CWF files but instead
   of being named like normal CWF's (###.BBS), they have the file name
   format of (title.CWF) where the root name 'title' is a 1-8 character
   name that reflects its intent.  As per the above example, you might have
   a file called (WORTHY.CWF).

   Master CWF files are standard Opus OEC text files except that the first
   line is used by the User Manager CWF system as the title line to list
   when displaying a list of Master CWF's.  When a master CWF is attached,
   this first title line is ignored.
\\
;
;
\UMANEXP\ -----------------------------------------------------------------

i H E L P                      User Data Export                     Page 1 of 1 
L

   The EXPORT function outputs any combination of a selected list of user
   fields to a text file in MailMerge<tm> format.  That is, one line per
   record, fields enclosed in quotes, and separated by commas - also known
   as comma-delimited ASCII.  This format is compatible with most word
   processors and databases and is friendly with the BASIC language.

   To export, you create a field select list by pressing [ENTER] on the
   desired fields in A)dd mode or by directly entering the field codes
   in the field list with the E)dit command.  When the list is complete,
   press O)utput to edit/cofirm the output file's name and start output.

   Eg, selecting Logon_Name, Location, and Privilege would produce:

     "Bryan Briarswick","Upperlip, Uk","Sysop"
     "Panda Protocol","Downin, Australia","AsstSysop"
     "Jorg JooHoo","Coldin, Sweden","Worthy"
     "Walter Wazoo","Laxin, Usa","Privileged"
\\
;
;
;
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\OEM\ ---------------------------------------------------------------------

i H E L P                   Event Manager Help Index                        
L



      
HO
L - Overview                  
HT
L - About Event Times

      
HN
L - Event Navigation          
HF
L - Event Field Menu

      
HE
L - Event Editing

      
HS
L - Schedule Editing        
HESC
L - Quit this Help

   Enter: (CmdLtr), ESC=Quit: ONESTF|[+_.}Q
IOEMOVR
NOEMNAV
EOEMEVE
SOEMSCH
TOEMTIM
FOEMFLD
Q
[
;
;
;
\OEMOVR\ ------------------------------------------------------------------

i H E L P                        Overview                       Page 1 of 2 
L

 OEM edits the Opus schedule of electronic mail events by allowing you
 to add, delete, or modify them.  The schedule that is operated on is
 the one defined in either the Opus 'parm' file or, explicitly, in the
 oMan configuration file, oMan.CFG, via the "Schedule path" statement.

 OEM reads any existing files and displays the events, one per line in
 a Lotus-like format.  Each line is an event and all events, together,
 are called the 'schedule of events' or, simply, the 'schedule'.

 To edit the fields of an event, you select the event with the cursor
 keys and then use the appropriate field command letters to modify them.
 To add new events or to delete existing ones, you use the schedule edit
 menu invoked with the slash (/) key.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                     Overview (cont)                   Page 2 of 2 
L

 When OEM loads or saves a schedule, it first sorts it into a mandatory
 operational order.  However, it does not sort the events as you edit them
 so that their position is not changed before you are finished with them.
 The schedule edit menu's sort command will manually sort the schedule at
 your request.  Use that command if you wish to preview the final order.

 When starting, if OEM can't find the schedule, it will ask if you wish to
 create one.  YES, will initialize a new one with no entries.  You would
 then typically insert a number of virgin entries and edit them, as needed.

 When you are done, the Q)uit command will verify the schedule and, if any
 changes were made, will ask for permission to save it.  If confirmed, then
 the schedule is re-sorted and saved.  If not, no changes will be saved.
;
;
;
\OEMNAV\ ------------------------------------------------------------------

i H E L P                      Navigation                       Page 1 of 2 
L

 OEM uses much the same cursor key and WordStar key combinations to
 navigate the screen as in other oMan functions.

 Event selection commands           IBM_Key_Pad       Keyboard

 
HNEXT EVENT
L (prev page, if bottom) ... 
H[DOWN]
L ....... 
HCtrl-X
L
 
HPREV EVENT
L (prev page, if top) ...... 
H[UP]  
L ....... 
HCtrl-E
L
 
HNEXT PAGE
L of events (if any) ........ 
H[PgDn]
L ....... 
H+
L (plus)
 
HPREV PAGE
L of events (if any) ........ 
H[PgUp]
L ....... 
H-
L (minus)
 
HFIRST PAGE
L of events (if any) ....... 
H[Home]
L ....... 
H1
L (one)
 
HLAST PAGE
L of events (if any) ........ 
H[End] 
L ....... 
H0
L (zero)
--------------------------------------------------------------------------

i H E L P                      Navigation (cont)                Page 2 of 2 
L

 The currently selected event is marked by both a flashing cursor (
F_
L)
 and a flashing asterisk (
F*
L).  When you answer prompts or menus, your
 cursor may jump to the command area at the bottom of the screen but
 the flashing asterisk remains behind to indicate the selected event.

 OEM can edit schedules with as many events as Opus can handle by showing
 up to 16 events per screen page, using as many pages as necessary.  When
 there are more then 16 events, the PgDn and PgUp keys will flip forward
 or back, 16 events at a time.  Also, if you attempt to move the cursor
 past the top or bottom, an automatic PgUp or PgDn is executed.
;
;
;
\OEMEVE\ -----------------------------------------------------------------

i H E L P                      Events Edit                      Page 1 of 1 
L

 When the event you wish to edit is selected, you can then modify it by
 pressing the field edit key for the field you wish to change.  These keys
 are high-lighted at the top of the screen and briefly explained in a bit
 more detail in the bottom menu area.

 Command keys are sometimes not operational since some fields only apply
 to specific event type.  Attempting to use an inapplicable command will
 either be ignored or a message will announce that fact.

 Event fields may be a switch that enables or disables a feature, holds
 one of a list of values, or a variable item.  When it is a switch, then
 its command key will toggle it.  Otherwise, you will be prompted with a
 list of possibilities or be asked to enter a variable item.
;
;
;
\OEMSCH\ -------------------------------------------------------------

i H E L P                      Schedule Edit                    Page 1 of 1 
L

 The schedule editing functions have their own menu which is invoked
 with the slash (/) key.  These functions allow you to INSERT, DELETE,
 COPY, or SORT events in the displayed schedule.

 Power users might appreciate that there also is a set of single key
 commands that will invoke these same functions from the main screen:

 Action    Description                     ByMenu  Speed-Key

 
HCOPY
L .... Insert copy of selected event ... 
H/C       *
L (asterisk)
 
HDELETE
L .. Delete selected event ........... 
H/D       ^
L (circumflex)
 
HINSERT
L .. Insert virgin event ............. 
H/I       #
L (pound sign)
 
HSORT
L .... Sort events ..................... 
H/S       @
L ("at" sign)
;
;
;
\OEMTIM\ --------------------------------------------------------------

i H E L P                      Time Window                      Page 1 of 4 
L
OEM MainIdx

 Each event has a range of time in which it is to execute.  Called, its
 
HWINDOW
L, it is very important and has slightly different implications
 depending on the event type.  This window is defined by its 
HBEGIN
L and
 
HEND
L times which may in 
HLOCAL
L time, 
HUTC
L (Universal Time Coordinated),
 or a mix of both.  OEM will automatically take them into account when
 dealing with them.

 For 
HBehavior and Yell
L events, the window refers to the period of time in
 which the options of those events are to be in effect.

 For 
Hall other
L events (which result in a singular actions), the window
 means the time period in which the event will be attempted. As such, it
 should be set to minimum size (0-1 minute) to prevent repeated executions.
------------------------------------------------------------------------

i H E L P                      Time Window (cont)               Page 2 of 4 
L

 An event's Begin and End times can be entered in a number of different
 ways for convenience, time zone setting, or time zone conversion.

 
HTIME
L     The format is "[hour][:][minute][zone]" where the [] closes
          optional fields.  The colon is shown as optional because you
          can enter time as all digits (515) or with a colon (5:15). OEM
          will figure it out.

 
HZONE
L     The default zone for the time values is LOCAL time.  That is,
          as per whatever your local zone may be.  This is shown on the
          screen by a trailing "L".  Times can be set to be UTC or LOCAL
          zoned.  UTC means "Universal Time, Coordinated" which is the
          same as Greenwich Mean Time and LOCAL means your own time zone.
-----------------------------------------------------------------------

i H E L P                      Time Window (cont)               Page 3 of 4 
L

 
HZONE
L     When you enter the zone letter as a suffix to a time value,
 (cont)   the given time and zone are set, as given.  For example, if
          you enter 
i 515L 
L, the time is set to 
H05:15
L and the zone is
          unchanged and time is NOT converted, but left as entered.

 But, when you enter just a zone letter without a time and the entered
 zone is different than the displayed one, OEM will convert the existing
 time to the new zone with its built-in time zone converter.

 For example, if you are in EST and 
H5:15L
L is shown, entering 
i U  
L
 will convert it read 
H10:15U
L because UTC is 5 hours ahead of EST.

 Entering the same zone letter as already displayed does nothing.
------------------------------------------------------------------------

i H E L P                      Time Window (cont)               Page 4 of 4 
L


H Time Entry Examples (Assuming EST as the LOCAL zone) 
L

  Before   Entered  After   Notes

  
H01:00L
L   
i 9    
L   
H09:00L
L  Same zone.  Assumed to be "on the hour"
  
H11:00L
L   
i 515  
L   
H05:15L
L  Same zone.  Assumed colon.
  
H22:00L
L   
i 4:25 
L   
H04:25L
L  Same zone.  Explicit colon.
  
H04:00L
L   
i :30  
L   
H04:30L
L  Same zone.  Only minutes changed.
  
H09:10U
L   
i 5L   
L   
H05:00L
L  LOCAL zone. Time set as entered.
  
H07:30L
L   
i 900U 
L   
H09:00U
L  UTC zone.   Time set as entered.

  
H09:00U
L   
i L    
L   
H04:00L
L  Time converted from UTC to EST.
  
H04:00L
L   
i U    
L   
H09:00U
L  Time converted from LOCAL to UTC.
;
;
;
\OEMFLD\ --------------------------------------------------------------

i H E L P                    Fields: Index                      Page 1 of 2 
L

 For more info on any one field, press its high-lighted command key.
 Use the standard help control keys to move to other pages.

 
HA
L)ctivity.. Flips: Event Disabled (D), or ENABLED (.)
 
HT
L)ype...... Sets event type: B)ehav E)xit Y)ell H)old S)can
 
HD
L)ays...... Sets Days of the week on which the event is active
 
HB
L)egin..... Sets Starting time of event window
 
HE
L)nd....... Sets Ending time of event window
 
HP
L)riority.. Sets Priority: Norm=NoPrio Inf=AfterUser Force=AxeUser
 
HO
L)utCallDly Sets Delay mail call delay. 5=least delay, ie, most frequent
 
HR
L)eturnCode Sets ErrorLevel (Exit) or Offset to add to it (Behavior)
 
HL
L)ReqLimit  Sets maximum minutes allowed for File Requests (Behavior)

  
i Enter: (CmdLtr), ESC=Quit, HOME=TopIdx:
L ATDBEPORLYS<>$CFMEN|[_^.{}Q
AOEMF-A
TOEMF-T
DOEMF-D
BOEMF-B
EOEMF-E
POEMF-P
OOEMF-O
ROEMF-R
LOEMF-L
YOEMF-Y
SOEMF-S
<OEMF-<
>OEMF->
$OEMF-$
COEMF-C
FOEMF-F
MOEMF-M
EOEMF-E
NOEMF-N
Q
[
1OEM
{
^
;
;
;
\OEMFLD2\ -----------------------------------------------------------------

i H E L P                    Fields: Index (cont)               Page 2 of 2 
L

 
HY
L)ellSecs.. Sets paging duration in seconds for YELL events
 
HS
L)end-Mail. Flips: Allowing outbound mail (S), or not (.)
 
H<
L)LocalOnly Flips: Only mail costing UP TO 'Cost' (<), or ignore (.)
 
H>
L)LD-Only.. Flips: Only mail costing MORE than 'Cost' (>), or ignore (.)
 
H$
L)LocalCost Sets maximum cost for mail to be considered as LOCAL
 
HC
L)M:Crash   Flips: Send to ONLY to CM: systems (C), or not (.)
 
HF
L)ileReq's. Flips: Honoring FidoNet File Requests (F), or not (.)
 
HM
L)ail-Only. Flips: Limiting access to mail calls only (M), or not (.)
 
HE
L)xits..... Flips: Ignorance of After-Mail EXITS (N) or not (.)
 
HN
L)otes..... Sets optional 0-16 character remark for each event

  
i Enter: (CmdLtr), ESC=Quit, HOME=TopIdx:
L ATDBEPORLYS<>$CFMEN|[_^.{}Q
AOEMF-A
TOEMF-T
DOEMF-D
BOEMF-B
EOEMF-E
POEMF-P
OOEMF-O
ROEMF-R
LOEMF-L
YOEMF-Y
SOEMF-S
<OEMF-<
>OEMF->
$OEMF-$
COEMF-C
FOEMF-F
MOEMF-M
EOEMF-E
NOEMF-N
[
Q
1OEM
{
^
;
;
;
\OEMF-A\ --------------------------------------------------------------

i H E L P                    Fields: ActiveStatus               Page 1 of 1 
L
OEMFLD FldIdx
 This field indicates whether an Event is ENABLED or DISABLED.

 
H ENABLED
L: The A)ct column shows a period (.) indicating that the event
           is operational and will be executed if its conditions are met.

 
HDISABLED
L: The A)ct column shows a (D) indicating that the event is
           turned OFF and will be completely ignored by Opus.

    NOTES: Typically, a Sysop will disable an event when it is not
           applicable to the current schedule set up but may be of
           value at some later time or when experimenting or testing.
;
;
;
\OEMF-T\ --------------------------------------------------------------

i H E L P                    Fields: EventType                  Page 1 of 3 
L

 This field indicates an event's "type".  There are several types of events
 which influence the operation of Opus in different ways:

 
HBEHAVIOR
L: Defines how Opus 'behaves' within the time frame specified
           by its Begin/End times.  When active, it controls NetMail
           behavior and whether any Inbound Mail exits are allowed.
           NOTE: The LAST behavior that fits the run time is used.

     
HEXIT
L: Causes Opus to exit to DOS with a given ERRORLEVEL and are
           subject to the BEHAVIOR window in force when they execute.
           The actual ERRORLEVEL passed to DOS is the sum of the EXIT
           event's ERRORLEVEL and the OFFSET of the active BEHAVIOR.
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                    Fields: EventType (cont)           Page 2 of 3 
L

     
HHOLD
L: Causes Opus to delete all "no connect" marker files in the
           outbound area.  These files are created each time Opus connects
           with a destination but fails to communicate with it.  Typically
           this event is run once every 1-7 days.  Failure to delete these
           markers will stop further mailing to the indicated addresses.

     
HSCAN
L: Causes the Opus internal EchoMail scanner to scan for echo
           messages that need to be sent out.  It should be set to run as
           often as you want to update your echo links.
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P                    Fields: EventType (cont)           Page 3 of 3 
L

     
HYELL
L: Defines a window in which Opus will allow Sysop paging and
           the length of time each page will ring the console bell.
           For discontinuous time periods, use multiple YELL events.

     
HUSER
L: Defines a window in which Opus will adjust the caller's
           maximum session time and download limit based on the setting
           of two percentage adjustment values.

    
HNOTES
L: When a given event's 
fT
LYPE field is FLASHING, it means
           that the event is flagged to EXECUTE NOW! (See PRIORITY)
;
;
;
\OEMF-D\ --------------------------------------------------------------

i H E L P                    Fields: Days                       Page 1 of 1 
L
OEMFLD FldIdx

 The Days field specifies which days the event is to be run on.  If the
 current day has its day flag set, then it will execute at the specified
 time in that day.  Each day position has two or three possible states
 depending on event type.

 A period (.) means the event will NOT run on that day.
 A day letter means the event will execute on that day.

 EXIT events show selected days in UPPER or lower case. If lower case,
 it means the event has already run.  If UPPER case it has NOT run yet.
 The D)ay option, when used on EXIT events, has a submenu that allows
 either the setting of scheduled days or their run status.
;
;
;
\OEMF-B\ --------------------------------------------------------------

i H E L P                    Fields: BeginTime                  Page 1 of 1 
L
OEMFLD FldIdx

 The Begin time field specifies the time at which the event is to start.
 It consists of a 24 hour time value and a trailing zone flag and can
 have a different zone than the End time.

 This time value, together with the End time value, defines a period of
 time in which the event is to execute.

 EXIT events typically are 0-1 minute long as a wider time window may
 have to unwanted result of re-executing the event upon return to Opus.

 Refer to the Help Topic on Time Fields for more on time entry.
;
;
;
\OEMF-E\ --------------------------------------------------------------

i H E L P                    Fields: EndTime                    Page 1 of 1 
L
OEMFLD FldIdx

 The End time field specifies the time at which the event is to end.
 It consists of a 24 hour time value and a trailing zone flag and can
 have a different zone than the Start time.

 This time value, together with the Begin time value, defines a period of
 time in which the event is to execute.

 EXIT events typically are 0-1 minute long as a wider time window may
 have to unwanted result of re-executing the event upon return to Opus.

 Refer to the Help Topic on Time Fields for more on time entry.
;
;
;
\OEMF-P\ --------------------------------------------------------------

i H E L P                    Fields: Priority                   Page 1 of 1 
L
OEMFLD FldIdx

 The Priority field applies to EXIT events and specifies how Opus will
 handle the case where an event's start time was missed due to a late
 start or an user being on-line.

   
HNORMAL
L .... Event may execute but be skipped if start time passed.

   
HINFORMAL
L .. Event will execute, waiting until any caller logs off.

   
HFORCED
L .... Event will execute, terminating any caller logged on.

   
HEXECUTE
L ... Runs event immediately ignoring schedule and is shown
                   by a FLASHING event type code which stops when run.

   
HUSER
L ...... User Limiting. Adjusts (K)b or (S)ession by +/- %.
;
;
;
\OEMF-O\ --------------------------------------------------------------

i H E L P                    Fields: OCD                        Page 1 of 1 
L
OEMFLD FldIdx

 The Outbound Call Delay field applies to Behavior events and sets the
 delay that Opus will pause for between outbound calls to deliver the
 next mail item found in the outbound holding area.

 Its default is 5 with a range of 5-40, with 5 being the minimum delay
 which will result in the fastest rate of calling out.

 During periods wherein you normally have a lot of outbound mail, you
 will want to set a minimum delay to increase your chances of getting all
 of your mail out.  Too small a delay may miss some inbound calls.

 When you want to maximize your readiness for inbound calls or want to
 space out your dialing attempts, you'll want to use a larger delay.
;
;
;
\OEMF-R\ ---------------------------------------------------------------------

i H E L P                    Fields: Return Code                Page 1 of 1 
L
OEMFLD FldIdx

 An Exit Event's Return Code is the DOS ErrorLevel that, when added to the
 active Behavior Event's ErrorLevel Offset, is the DOS ErrorLevel that Opus
 will exit with.  Usually, Behavior events have their ErrorLevel Offset set
 to zero, so the DOS ErrorLevel used will be the same as the Return Code of
 the Exit Event.  An Exit Event's RetCode can be (6-254).

 Error levels are used to selectively control your batch file wherein
 a series of "IF ERRORLEVEL == n" can detect the errorlevel exited with.

 For the "M" (Mailer Type) event, the screen space of the errorlevel base
 and offset values is used to show the Mailer Type (OpusInt or ExtLoad).
 This field shares the same column as a Behavior Event's Request Limit but
 has no relationship to it.
;
;
;
\OEMF-L\-----------------------------------------------------------------------

i H E L P                    Fields: File Request Limit         Page 1 of 1 
L
OEMFLD FldIdx

 A Behavior Event's "File Request Limit" sets a limit on total minutes that
 will be allowed for file requests during that behavioral event.  It's
 range is from 0 to 255 with 0 meaning "no limit".

 Set this to an appropriate value when you want to limit File Requests
 during periods where, eg, you want to maximise user access or netmail
 traffic with your system.

 This field shares the same column as an Exit Event's "Return Code" but has
 no relationship to it.
;
;
;
\OEMF-Y\ --------------------------------------------------------------

i H E L P                    Fields: YellSeconds                Page 1 of 1 
L
OEMFLD FldIdx

 The Yell Seconds field applies to Yell events and sets the maximum
 number of seconds for which the local console will page the sysop
 before Opus responds with a "Sysop Unavailable" message.

 Set this to your own taste.  A value of 20-30 seconds is a good length
 of time as it is long enough to let you hear it if you are around to
 hear it, at all, and short enough not to be excessively annoying if
 you don't feel like responding.
;
;
;
\OEMF-S\ --------------------------------------------------------------

i H E L P                    Fields: SendMail                   Page 1 of 1 
L
OEMFLD FldIdx

 The Send field applies to Behavior events and is a master switch that
 enables or disables the sending of any outbound mail.

 When set ON, as shown by an (S) on the screen, Opus will attempt to
 send any pending outbound mail if all other conditions are met.

 When set OFF, as shown by a period (.), Opus will not send any mail.

 Send is typically always on except in those cases where you want
 maximum assurance that mail will NOT be sent such as during periods
 where you want maximum access to human callers or for testing.
;
;
;
\OEMF-<\ --------------------------------------------------------------

i H E L P                    Fields: LocalOnly                  Page 1 of 1 
L
OEMFLD FldIdx

 The Local-Only field applies to Behavior events and limits outbound
 mail calls to only those destinations whose nodelist call cost is less
 than (or equal) to the maximum local call cost.

 It is indicated by a "less than" sign (<) next to max local cost field.

 In the typical case where the maximum local call cost is set to zero,
 this setting results in only local, non-toll calls being made.

 You normally want to set this during times of peak Bell charge rates to
 prevent long distance outbound calls during those expensive times.
;
;
;
\OEMF->\ --------------------------------------------------------------

i H E L P                    Fields: LD-Only                    Page 1 of 1 
L
OEMFLD FldIdx

 The LD-Only field applies to Behavior events and limits outbound mail
 calls to only those destinations whose nodelist call cost is greater
 than the maximum local call cost.

 It is indicated by a "more than" sign (>) next to max local cost field.

 In the typical case where the maximum local call cost is set to zero,
 this setting results in only toll calls being made.

 This might be used when you want to make maximum use of low Bell charge
 rate periods by not wasting time calling local destinations which can
 be called at other times without charge.
;
;
;
\OEMF-$\ --------------------------------------------------------------

i H E L P                    Fields: LocalCost                  Page 1 of 1 
L
OEMFLD FldIdx

 The Maximum Local Cost field applies to Behavior events and sets the
 maximum nodelist message cost a destination can have to be considered
 as a LOCAL call.  It is expressed in cents, ie, 
H200
L means $2.00.

 Its default (and typical) value is 0 which means that only mail destined
 for addresses whose nodelist cost field is zero are to be consider as
 local mail.

 If you regularly exchange mail with locations for which there is a
 minimal toll charge, you might want to set this value slightly higher
 to allow the sending to them even during peak rate time periods.
;
;
;
\OEMF-C\ --------------------------------------------------------------

i H E L P                    Fields: CM-Only                    Page 1 of 1 
L
OEMFLD FldIdx

 The "C" field applies to Behavior events and limits the sending of mail
 to only those systems which are marked as "CM:" in the nodelist.

 When OFF, Opus will ignore a system's CM: status.

 In general, turn the "C" flag on when outside of Zone Mail Hour and OFF
 when within it to allows all mail to go out.
;
;
;
\OEMF-F\ --------------------------------------------------------------

i H E L P                    Fields: FileRequests               Page 1 of 1 
L
OEMFLD FldIdx

 This field applies to Behavior events and controls whether Opus is to
 honor any incoming File-Requests.

 If set ON, the requested files, if available, will be sent.

 If set OFF, the request will denied.

 It is generally recommended that File Requests not be honored during
 the standard mail hour so that net mail will not be impeded.
;
;
;
\OEMF-M\ --------------------------------------------------------------

i H E L P                    Fields: MailOnly                   Page 1 of 1 
L
OEMFLD FldIdx

 This field applies to Behavior events and controls whether Opus will
 allow human callers to log on or to limit itself to mail exchanges only.

 If set ON, human callers will be refused.

 If set OFF, human callers are allowed to log on.

 It is generally recommended that human callers not be allowed to log
 on during the standard mail hour as that would hinder mail exchange.
;
;
;
\OEMF-E\ --------------------------------------------------------------

i H E L P                    Fields: NoExits                    Page 1 of 1 
L
OEMFLD FldIdx

 This field applies to Behavior events and controls whether any exits
 that have been specified for execution after receipts of net mail will
 occur or not.

 When ON, any exits set for after mail receipts are ignored.

 When OFF, any exits set for after mail receipts will be allowed.

 This setting might be used for those times when you want to postpone
 any, perhaps lengthy, external mail post-processing procedures until
 a more appropriate time such as in the early morning hours.
;
;
;
\OEMF-N\ --------------------------------------------------------------

i H E L P                    Fields: Notes                      Page 1 of 1 
L
OEMFLD FldIdx

 This field is not used by Opus and is solely for purpose of attaching a
 remark of up to 16 characters to each event.  The remarks are stored
 in a special location within the Opus schedule for later loading and
 recall the next time you edit the event file.

 Schedule remarks are an innovation, new with Opus 1.10.  As such, it
 might be possible that the use of another event manager that does not
 understand their use will lose them through the editing process.  If
 that happens, it should not (hopefully) effect the actual schedule.
;
\\
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\OHM\ ---------------------------------------------------------------------

i H E L P                    Command Summary                    Page 1 of 1 
L

 PgUp/Dn - Show prev/next page        H - Make item HOLD   (ForPickup)
 Hom/End - Show 1st/last page         N - Make item NORMAL (Routable)
   Up/Dn - Scroll 1 line Dn/Up        D - Make item DIRECT (UnRoutable)
                                      C - Make item CRASH  (Send ASAP)
       ! - Clear/Redisplay screen     L - Make item LEAVE  (NoSend)
       $ - Cleanup trivial files      A - Change an item's dest address
       F - Set file types shown       E - Erase (DELETE) an item
       Z - Display another Zone       X - Show bundled msg headers or text
       ? - Displays this screen       I - DOS directory (Default=HoldArea)
       * - Run a DOS Command          S - Send file(s) to address(es)
       % - Recycle bundle to inbound  R - Request file(s) from address
   Esc,Q - Return to Manager          U - Request update(s) from address
       \ - End Oman, Exit to DOS
                                          (PgDn for Overview)
;
;
;
--------------------------------------------------------------------------

i H E L P                       Overview                        Page 1 of 2 
L

 The Outbound Manager allows you to easily inspect, modify, and maintain the
 directory where mail items are waiting to be sent over the network.  The
 items that can be seen (and maintained) there are:

   o Bundles ........... Messages that are grouped into deliverable bundles.
   o File Attach Lists.. Lists of files to sent, created by mail processors.
   o Compressed Mail ... Bundles compressed by archivers (sent by attach)
   o Marker Files ...... Files that note bad connects or incomplete sends

 Mail processors create all of these items when they are run periodically
 at prescheduled times or, on demand, when a Sysop manually invokes them.

                                 (continued)
;
--------------------------------------------------------------------------

i H E L P                     Overview (cont)                   Page 2 of 2 
L

 Normally, little intervention is needed in the outbound area. However, due
 to message misaddressing, the desire to create a quick file attach, or to
 monitor the status of any pending mail, the Outbound Manager is used.

 When invoked, the Outbound Manager, displays any pending mail destined for
 the current zone in a tabular form with one mail item (object) per line
 with logically related objects grouped together and sorted by address.

 Using the manager's commands, you can readdress or inspect mail bundles,
 erase most objects (including marker files), and/or create File Attach or
 File Request Lists.  Review the command summary for a list of commands.
 If you use separately defined outbound areas (zoned directories), you can
 display them using the Z)one command.
;
;
;
\OHMXFR\ --------------------------------------------------------------

i H E L P                 Send or Request Files                 Page 1 of 3 
L

 This multiple file transfer screen is used by both the S)end and R)equest
 file functions to enter 1-14 files and the 1-14 addresses to send to, or
 request them, from. On execution, a separate file send (or request) list
 is generated for EACH address that specifies ALL of the entered files.

 If needed, change the default priority of the order with the (P) key.

 Use (A) to begin entry of the desired list of FidoNet addresses.  While
 in address entry mode, the "files" column is used to display the system
 name of the addresses entered for reference.  ESC ends address entry.
 If any files had previously been display, they are temporarily cleared.

                                     (cont)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              Send or Request Files (cont)             Page 2 of 3 
L

 Use (F) to begin entry of the desired list of files to send or receive.
 You can enter 12 chacaters in REQUEST mode and 40 in SEND mode. If the
 (A) option was used, any system names are cleared.  ESC ends file entry.
 When doing REQUESTs, CR on a file field jumps to the password field.

 Use (E) to E)xecute the file transfer order.  It will prompt you for
 confirmation.

 While in (A)ddress or (F)ile entry modes, you can use the [Up]/[Down],
 [PgUp]/[PgDn], or ^E/^X keys to move up or down a column.  Cursoring
 out of a field acts like a [CR], finishing the entry.  You can leave
 some rows empty and they will just be ignored.

                                     (cont)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P              Send or Request Files (cont)             Page 3 of 3 
L

 After entering a list of addresses, you can save it to a file with the
 (S) command.  It creates a simple ASCII file with one address per line
 in the same format as on screen.

 In an opposite fashion, the (L) command loads an external address list
 made with either the (S) command or with any text editor.

 When switching between (F)ile and (A)ddress modes, the 2nd column shows
 either the system name belonging to the addresses or the files entered
 thus far.  You can switch back and forth between these two modes without
 losing anything.  (E)xecute or (Q)uit terminates the function.
\\
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\NED\------------------------------------------------------------------

i H E L P                       Command Summary                     Page 1 of 1 
L

  PgUp/Dn - Prev/Next Page         Left/Right - Prev/Next Node
 Home/End - 1st/Last node             Up/Down - Prev/Next Node

        A - Edit node's address             P - Edit Node's PASSWORD
        S - Edit System Data                C - Edit Call Cost (actual)
        O - Edit Operator Name              U - Edit User Cost (charged)
        G - Edit General Info field         M - Edit Modem Type field
        T - Edit Telephone Number           @ - Edit Node's maximum baud
        H - Edit node's HUB address         B - Edit Bit flag fields

        F - Find a node, several ways       R - Read (Restore) node data
        L - List nodes, several ways        W - Write (Save)   node data
        I - Insert new node                 ! - Redisplay screen (line noise)
        D - Delete current node

    Esc/Q - Return to Manager               ? - (This) Onscreen Help
\\
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\GDAT\-----------------------------------------------------------------

i H E L P                   Global Data Overview                    Page 1 of 1 
L

   The Global Data Editor allows you to edit the data which is global in
   nature.  Presently, three items are in this category: The Quotes File
   Pointer, the System Call Count, and the Maximum Task.

   Quotes Pointer: Incremented to next quote at each logon.

   Call Count....: Incremented by 1 at each logon.

   Maximum Task..: Highest task used (COMMON DATA file; future use).

   Opus stores and updates the Quotes Pointer and Call Count in the Schedule
   file defined for the current task.  If a COMMON DATA file is (optionally)
   defined, then the Call Count is updated in BOTH but the Quotes Pointer is
   only updated in the COMMON file.

   Since multiline systems typically have a separate schedule for each task
   and have a COMMON DATA file defined, the Schedule's Call Count will show
   the calls per task (ie, line) and the COMMON DATA Call Count will show
   the total calls to the system, across all lines.
;
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
; ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
;
\CALLSTAT\----------------------------------------------------------------

i H E L P                   Caller Info Screen                      Page 1 of 2 
L

   The Caller Info Screen displays information about the current or last
   callers for each of up to 18 Opus tasks that you run, one task per
   line; any more are ignored.  To make the display real-time, this
   process is repeated every 15 seconds (or as set in OMAN.CFG).  The
   data displayed for each task includes:

   TaskNo ........ Task No of the Opus that is (or was) running.
   Who Called .... Name of User (and locale) who is (or was) on line.
   Logon Time .... Date and time the call was received.
   Time Given .... Minutes allotted to the caller.
   Time Used ..... Minutes used thus far (active lines only)
   Time Remaining  Minutes remaining     (active lines only)

   NOTES│ NetMail sessions and user pre-logons are not currently reported.
        │ If RingMode is BEEP, you will hear a beep if the mode rings.
        │ If RingMode is EXIT, you will exit OMAN if the mode rings.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i H E L P             Caller Info Screen (cont)                     Page 2 of 2 
L

                Caller Info Screen's Menu Options

  Refresh=##s   Displays the current refresh cycle time which will usually
                be 15s, unless overridden in OMAN.CFG.

  ENTER ....... Cancels the current refresh wait period, updates the
                screen, immediately, then resumes normal refresh cycling.

  R)ingMode ... If OMAN was started with RingMode set to BEEP or EXIT,
                then the R command will toggle RingMode through its OFF,
                BEEP, and EXIT modes. If OMAM was started with RingMode
                set to OFF, this command has no effect.

  ESC, Q ...... Exit the Caller Info screen, returning to the Oman menu.
       \ ...... Exit the Caller Info screen, exiting directly to DOS!
\\